Bahasa Rust: Kebutuhan akan Rust yang Tidak Aman

Bahasa Tersembunyi di Dalam

Rust memiliki rahasia: sebenarnya dua bahasa dalam satu. Sementara Rust Aman adalah pelindungmu, kompiler Rust pada dasarnya konservatif. Ia mengikuti filosofi ketat: lebih baik menolak program yang sah dan aman daripada secara tidak sengaja membiarkan satu program berbahaya. Hal ini menciptakan celah antara apa yang bisa dilakukan perangkat keras dan apa yang bisa dibuktikan oleh kompiler.

Realitas yang Kaku

Bayangkan kompiler sebagai penjaga pintu yang ketat. Dalam contoh kode kita, pengawas pencocokan jika y berlaku untuk seluruh kelompok pola (4 | 5 | 6). Kaku ini prioritas mencerminkan cara Kerangka Peminjaman bekerja; ia menerapkan aturan global tanpa kompromi terhadap memori kamu. Namun perangkat keras komputer pada dasarnya secara inheren tidak aman; ia tidak memahami kepemilikan atau umur. Untuk membuat alat berkinerja tinggi seperti split_at_mut, kita harus masuk ke dalam Rust yang Tidak Aman 'lubang penyelamatan' untuk melakukan operasi yang secara teknis aman tetapi secara logika terlalu kompleks bagi analisis statis kompiler.

Celah antara lingkaran merah dan hijau adalah tempat Rust yang Tidak Aman hidup—memungkinkan kita mencapai potensi penuh dari perangkat keras saat analisis statis gagal.

TERMINALbash — 80x24

> Ready. Click "Run" to execute.

QUESTION 1

What is the primary reason for the existence of Unsafe Rust?

To allow programmers to write C code in Rust.

Because static analysis is conservative and may reject valid code.

To disable the borrow checker entirely for the whole project.

Because hardware is naturally safe and doesn't need checks.

QUESTION 2

In the pattern 4 | 5 | 6 if y, what does the guard if y apply to?

Only the value 6.

Only the values 5 and 6.

The entire pattern group (4, 5, and 6).

It depends on the value of x.

❌ Incorrect

The guard acts on the combined group (4 | 5 | 6).

QUESTION 3

Does Unsafe Rust turn off the borrow checker?

Yes, it disables all safety checks within the block.

No, it only provides 'superpowers' like raw pointer dereferencing.

Yes, but only for variables declared inside the block.

No, it actually makes the borrow checker stricter.

QUESTION 4

Why is computer hardware considered 'inherently unsafe'?

It lacks the ability to execute instructions.

It does not understand Rust's ownership and lifetime rules.

Hardware is prone to physical failure.

Hardware requires a garbage collector to function.

QUESTION 5

Which scenario necessitates an unsafe block?

Sorting a vector of integers.

Splitting a mutable slice into two non-overlapping parts.

Creating a new HashMap.

Using a match statement with a guard.